WordPress-sites lopen risico op backdoor door hack bij plug-inmaker TeamUpdraft

Beheerders van WordPress-sites kunnen een backdoor op hun systemen hebben doordat aanvallers klantengegevens en encryptiesleutels hebben gestolen bij TeamUpdraft. Dat bedrijf maakt plug-ins voor back-up en herstel van WordPress-installaties. Klanten moeten nu diverse maatregelen nemen.

De maker van UpdraftPlus, UpdraftCentral, UpdraftVault en UpdraftClone geeft gebruikers uitleg over de hackaanval, die het bedrijf afgelopen weekend ontdekte. In reactie heeft het bedrijf de toegang van de aanvallers geblokkeerd, klanten uit hun onlineaccounts uitgelogd, de beveiliging op zijn website gereset en encryptiesleutels vervangen. Het komt 'zo snel mogelijk' met een update voor UpdraftPlus die automatisch UpdraftCentral-verbindingen van voor de hackaanval verbreekt.

Wachtwoorden wijzigen, sleutels wissen

Klanten die zelf UpdraftCentral draaien, zijn volgens TeamUpdraft niet geraakt door dit beveiligingsincident. Bij de uitleg over de hackaanval geeft het bedrijf ook instructies voor gebruikers van zijn verschillende producten. Klanten met een account bij teamupdraft.com moeten hun wachtwoorden daarvoor wijzigen. Als ze tweefactorauthenticatie gebruiken, moeten ze die resetten in hun account op de site van de pluginmaker.

Gebruikers van clouddienst UpdraftCentral moeten hun sites stuk voor stuk veiligstellen, omdat via die clouddienst commando's zijn te sturen aan verbonden sites. Voor elke site moeten klanten inloggen op het WordPress-dashboard van die site om daar de verbinding met UpdraftCentral te verbreken. Dit gebeurt door de verbindingssleutel te wissen.

Accounts en plug-ins controleren

Daarna moeten beheerders nog controleren of er onbekende beheerdersaccounts staan in het gebruikersoverzicht. Als die er zijn, moeten beheerders die wissen. Verder moeten beheerders onbekende plug-ins verwijderen en de wachtwoorden voor alle beheerdersaccounts wijzigen. "Als je iets verdachts vindt, overweeg dan om de site te herstellen vanaf een back-up die is gemaakt vóór 17 oktober", adviseert TeamUpdraft.

Gebruikers van UpdraftVault zijn door het bedrijf al ontkoppeld. Hierdoor werken back-ups nu niet meer. Beheerders moeten voor elke WordPress-site inloggen op het dashboard en daar opnieuw verbinding maken met UpdraftVault. Daarbij moeten ze wel een nieuw wachtwoord gebruiken voor hun account bij teamupdraft.com.

Gebruikers van UpdraftClone hoeven alleen actie te ondernemen als ze sleutels hebben gedeeld met hun eigen klanten. TeamUpdraft heeft de sleutels van zijn kloonproduct vervangen voor gebruikers. Als zij die met hun klanten hebben gedeeld, moeten ze nu dus de nieuwe sleutels doorgeven. De oude sleutels werken niet meer.

Wel waakzaam zijn

Gebruikers van het gratis UpdraftPlus die geen account bij teamupdraft.com hebben, hoeven nu niets te doen. Wel moeten alle gebruikers van TeamUpdraft-producten waakzaam zijn voor phishing. De aanvallers hebben namelijk naast versleutelde wachtwoorden, encryptiesleutels en instellingen voor tweefactorauthenticatie ook veel klantengegevens gestolen. Deze data omvat namen, e-mailadressen, factuuradressen en de bestelgeschiedenis. Beheerders bespreken de impact onder meer in een thread op Reddit.

TeamUpdraft iconen. Bron: TeamUpdraft

Reacties (26)

[mayhem]

Mijn mening: back-ups moeten geregeld worden door de infra (lees hosting), niet door de applicatie.

[HenkEisDS]

Eens. Ik krijg het gewoon gratis van mijn hostingprovider, waarom zou ik dan externe afhankelijkheden toevoegen en er ook nog voor betalen?

[mpol]

De backup wil je natuurlijk plaatsen op een andere locatie, niet bij de hosting. Als de hosting afbrandt is je backup ook weg.

[JeroenV_]

Precies daarom gebruiken wij updraft; om een backup te maken naar onze eigen Azure omgeving

[Pjotr Pinda]

Mijn mening: Een betrouwbare backup van een applicatie kan je het beste overlaten aan de applicatie zelf. Stel je een applicatie voor die bestaat uit database, frontend, backend, verspreid over een tiental systemen. Hoe ga je die consistent backuppen vanuit je infra?
Onmogelijk.
Een goede applicatie is ontworpen met beheerbaarheid, en dus ook backup, in het achterhoofd.

[MrWiggle]

Dit laat wel weer zien hoe kwetsbaar een website kan worden door alle externe afhankelijkheden. Zelfs een back-upplug-in, die juist voor extra zekerheid moet zorgen, kan een risico vormen.

WordPress is op zichzelf niet het probleem, maar voor relatief eenvoudige websites vraag ik me steeds vaker af of zo'n uitgebreid ecosysteem van plug-ins en koppelingen eigenlijk wel nodig is.

Minder afhankelijkheden betekent natuurlijk niet automatisch betere beveiliging, maar het maakt het beheer en het aanvalsoppervlak wel een stuk overzichtelijker.

[WPbeveiligen]

Een maximaal aantal plugins en administratoren met beheerrechten is een goed begin.
Het is wel jammer dat AI nu heel veel "hackers" de kans geeft om de plugins op hoog niveau door te lichten op mogelijke lekken.

[Klauwhamer]

Nee, het is problematisch dat WordPress dit soort draken van code faciliteert. Steeds dat vingertje naar plugins in plaats van het framework is al jàren misplaatst.

[jannes_beterams]

Er zijn genoeg lekken in de Wordpress core zelf lately. Maar Drupal spant toch echt de kroon, man wat een berg CVE's komen daar voorbij.

[Mars Warrior]

Als deze plug-in was gekoppeld aan een gebruiker met beperkte rechten, dan had de hele aanval gewoon niet mogelijk geweest.

Want een gebruiker met beperkte rechten mag geen plug-ins installeren.

Maar dat is natuurlijk lekker achteraf praten. Maar op deze manier kun je wel heel veel problemen voorkomen.

Ik ken zelfs sites die in een soort lockdown modus staan. Dat wordt gewoon door WordPress ondersteund. Daarbij kun je geen nieuwe gebruikers aanmaken en geen plug-ins installeren. Je kunt dus wel gewoon plug-ins bijwerken.

[Reactie gewijzigd door Mars Warrior op 19 oktober 2026 20:44]

[Little Penguin]

Gebruikers van clouddienst UpdraftCentral moeten hun sites stuk voor stuk veiligstellen, omdat via die clouddienst commando's zijn te sturen aan verbonden sites.

Het op afstand uit kunnen voeren van commando's is ook helemaal niet zo'n goed idee, waarom dacht men dat dit een goed idee zou zijn? Dit zou expliciet aangezet moeten worden voor dit gebruikt kan worden, dan is het tenminste nog een keuze.

Ik geef toe dat het remote updaten van plug-ins en WordPress zelf ook code ophaald van een remote host, maar dat is dan wel specifiek een WordPress of een plug-in-update.

Als ik het goed begrijp wordt er via deze exploit echter een willekeurige plug-in toegevoegd en dan wordt het wel heel gemakkelijk om besmette code binnen te krijgen.

Uit het bericht op patchstack:

Run this check even if you have never used UpdraftCentral. Because of the default-ticked checkbox on the TeamUpdraft.com account screen, plenty of sites hold a key that nobody deliberately created

Dit is ook wel lekker onhandig, zodra je dus het standaardpad qua installatie afgegaan bent is de website waar je deze plug-in geïnstalleerd hebt dus zeer waarschijnlijk lek. Nog een default die niet standaard aan zou moeten staan.

[Faeron]

Wordpress is ook nooit ontworpen en gemaakt met beveiliging in gedachte. Het is een brok spaghetti-code. Ik heb in het verleden meerdere workshops secure webdevelopment gegeven, waarbij ik Wordpress code gebruikte als voorbeeld van hoe het niet moet.

[WPbeveiligen]

WordPress wel maar die plugin mogen te veel. Dan zijn er ook nog eens 76,000 gratis plugins, en minimaal evenveel premium plugins gemaakt door jan en alleman.. tja.

Bij goed beheer is het wel te doen, maar zomaar even wat plugins erin knallen en wat admins zonder beveiligingsregels.. dat kan alleen als het een hobby-site is.

[Klauwhamer]

Nee, ook dan niet. De hobby-site kan alsnog onderdeel worden van een botnet dat services en diensten terroriseert. De mentaliteit "alleen als het een hobby-site is" kan al jàren niet meer.

[Xilonz]

Hosting partijen houden dat echt wel in de gaten. Daarnaast, een botnet in PHP? Dat is het meest inefficiënte manier voor het draaien van een botnet wat ik me kan bedenken. PHP heeft (standaard) niet een manier om lang lopende scripts te draaien.

[Archcry]

Inefficiënt is nou niet echt een probleem als het jou (lees: de hacker) geen geld kost.

[Klauwhamer]

Er zijn genoeg plugins voor WP waar laagdrempelige RCE's in zaten, en actief misbruikt werden ondanks hosting partijen. Efficientie speelt ook geen rol van betekenis bij dit soort exploits. En dan ben je gewoon gezien, wel of geen PHP. Het is mij niet duidelijk waarom je dit opvoert.

[Reactie gewijzigd door Klauwhamer op 19 oktober 2026 21:38]

[Xilonz]

Ik denk dat je geen idee hebt wat voor maatregelen de hosting partijen van hobby-sites allemaal nemen. Er glipt echt wel eens wat tussen door, maar ja, 40% het internet draait WordPress, dan gaat er heus wel eens wat mis.

- Automatische patches
- Firewalls
- Netwerk monitoring
- Automatische updates (ook onderdeel van WordPress zelf)

Juist omdat er zoveel WordPress sites zijn, kan er zo effectief tegen beveiligd worden.

Mbt botnets: Ik kende het niet, maar blijkbaar bestaat het wel. Gelukkig nog nooit in de praktijk tegen gekomen.

[Klauwhamer]

Waarom beticht je mij geen idee hier van te hebben, als blijkt dat je dat zelf domweg niet hebt? Maatregelen of niet, Wordpress en plugins zorgen voor een gigantische attack vector die steeds tienduizenden zo niet honderdduizenden websites kwetsbaar maakt met alle goed gedocumenteerde gevolgen van dien.

En wat bedoel je met "40% van het internet draait WordPress" -- wat is "het internet" hier precies? WordPress is een slecht produkt dat nog slechtere plugins faciliteert. En daar is de kous mee af.

[Reactie gewijzigd door Klauwhamer op 19 oktober 2026 22:48]

[Xilonz]

Ik hoor dit vaker, maar WordPress zelf heeft relatief weinig CVE's voor zijn formaat.
'spaghetti-code' staat niet gelijk aan onveilige code - sterker nog, als je kijkt naar hoe andere php-software (symfony, laravel, drupal, etc) in elkaar steekt, is WordPress nog wel de makkelijkste om door te lichten.

Je ziet dat veel bedrijven hun CMS totaal dichttimmeren onder het mom van veiligheid, waardoor de klant totaal zijn vrijheid verlies en met hoge kosten komt te zitten voor de meest simpele aanpassingen.

Je moet het wat mij betreft ook meer zien als besturingsysteem, het heeft een enorm ecosysteem er omheen, er is gewoon geen goed open source alternatief voor, en dat gaat voorlopig ook niet komen.

[Little Penguin]

Er zijn hier echter wel twee onderscheiden zaken, de ene is WordPress - het weinig dat ik er van gezien heb vond ik niet per definitie slecht (zo is er veel mogelijk rond posts en als je dat fenomeen gebruikt kun je zonder veel werk ook best mooie dingen aan WordPress toevoegen).

Wat natuurlijk wel geldt dat is dat plug-ins wel een veiligheidsrisico vormen, zeker als je niet weet waar ze vandaan komen...

Het andere is deze specifieke plug-in die dus domweg allerlei zaken mogelijk maakt op afstand die gewoon nooit standaard mogelijk had moeten zijn. (Nu kun je stellen dat WordPress dat weer onmogelijk had moeten maken, maar dat is met PHP niet mogelijk vziw).

[Faeron]

Niet per definitie slecht zeg je… hmm… Al eens een framework bekeken waar het MVC model goed in is doorgevoerd en er een startpunt (bijv een index.php) is voor iedere request? Als je zo'n aanpak vergelijkt met Wordpress, vind je Wordpress dan nog steeds oke?

[Basszje]

Gaat dus zo te lezen alleen om gebruikers die een account hebben bij de dienst. Niet als je alleen de plugin gebruikt zonder extra accounts (gratis gebruikers)

[WPbeveiligen]

Sleutels intrekken van updraftcentral als je die hebt en kijken of er beweging is in de files/admin users.

Ik gebruik het zelf niet maar TeamUpdraft heeft dit standaard aangevinkt staan als je een pro licentie hebt en de modules wilt gebruiken op een site.

Kortom, elke keer uitvinken want wie gaat updraft (backupplugin) nu ook als management tool gebruiken..?

Hopelijk hebben alle sites goede beveiliging, logboeken zodat ze kunnen kijken of er al users aangemaakt zijn, aanpassingen zijn verricht etc.

Succes!

[JeroenV_]

Gisterochtend kwam er een mail binnen van onze monitoring; website is plat.
Vreemd, niemand was iets aan het doen daarmee op dat tijdstip. De wp-admin benaderen gaf een kritische fout, en daarop stuurde WP een mail met een plugin die de fout zou veroorzaken. Niemand kende de plugin en ook erop googlen gaf geen resultaat.

Toen de site gefixt was zagen we in de logs dat de plugin geinstalleerd zou zijn door iemand die op dat moment in de auto zat, en na verdere inspectie bleek in het request te zien te zijn dat het via Updraft was gegaan. Toen we daarop gingen zoeken kwamen we een Reddit thread tegen waarin bleek dat we niet de enige waren, maar omdat ze dus random plugin namen gebruikten duurde het even voordat het vindbaar was.

Pas na het aanmelden van een ticket kregen we een mail van updraft dat er inderdaad een incident was geweest, tikkeltje laat.